calling a script at startup

Patrzysz na archiwalną wersję wątku "calling a script at startup" z forum alt.pl.comp.os.linux.fedora

Gary Wessle - 1 Paź 2006, 20:23

Hi

I am experimenting to run my own daemon on start up.

I added this line to my /etc/inittab
oc:5:respawn:/home/fred/bin/my_daemon

here my daemon calls a C++ program
****************************************************************
$ cat /home/fred/bin/my_daemon.sh
#!/bin/sh
./proj

here what the C++ program does
****************************************************************
here what it does  
~:$ ./proj
man ...................

and it is locate in my home dir.

is this all fine?

thanks

Darek - 2 Paź 2006, 01:49


Hi

I am experimenting to run my own daemon on start up.

I added this line to my /etc/inittab
oc:5:respawn:/home/fred/bin/my_daemon


Create file in "/etc/init.d" directory.

Bogdan (bogdro) - 2 Paź 2006, 04:55


Hi

I am experimenting to run my own daemon on start up.

I added this line to my /etc/inittab
oc:5:respawn:/home/fred/bin/my_daemon


 Like told before, you should put a file in the /etc/init.d directory
and name it properly, like "S66mydaemon". Better would be to create a
link of this name, which would point to the script.
 Why not use the /etc/rc.local file with execution in background, like:
 [/etc/rc.local:]
        ...
        ...
        /home/fred/bin/my_daemon.sh &
[end of file /etc/rc.local]
or even use directly:

        /home/fred/bin/proj

(remember to add a '&' to the end of the line above, if the C++
program is not yet a real daemon).

here my daemon calls a C++ program
****************************************************************
$ cat /home/fred/bin/my_daemon.sh
#!/bin/sh
./proj

here what the C++ program does
****************************************************************
here what it does  
~:$ ./proj
man ...................

and it is locate in my home dir.

is this all fine?


 One more thing: in /etc/inittab, you run a file called
"/home/fred/bin/my_daemon", but in /home/fred/bin/ there is
"my_daemon.sh". Be sure to change the name or make a link.

Gary Wessle - 2 Paź 2006, 14:40



| Hi

| I am experimenting to run my own daemon on start up.

| I added this line to my /etc/inittab
| oc:5:respawn:/home/fred/bin/my_daemon

 Like told before, you should put a file in the /etc/init.d directory
and name it properly, like "S66mydaemon". Better would be to create a
link of this name, which would point to the script.
 Why not use the /etc/rc.local file with execution in background, like:
 [/etc/rc.local:]
   ...
   ...
   /home/fred/bin/my_daemon.sh &
[end of file /etc/rc.local]
or even use directly:

   /home/fred/bin/proj

(remember to add a '&' to the end of the line above, if the C++
program is not yet a real daemon).


thanks Bogdan;

the whole concept is very new to me, so I am learning and trying to
get the bigger picture.

what do you mean by "if the C++ program is not yet a real daemon"?

if I add
/home/fred/bin/proj &
to the end of /etc/rc.local, how does this re-establish my connection
with the server?
I mean, is there a return value from proj to let init know to restart
it?

what proj does is;
first connect to the server using uername/password.
send/receive info to/from the server.
if I use isLogged() in my C++ to return a false to init so it restarts
it, is not that the same as getting the C++ code to reconnect with out
needing a daemon?

Bogdan (bogdro) - 3 Paź 2006, 05:27




| Hi

| I am experimenting to run my own daemon on start up.

| I added this line to my /etc/inittab
| oc:5:respawn:/home/fred/bin/my_daemon
|  Like told before, you should put a file in the /etc/init.d directory
| and name it properly, like "S66mydaemon". Better would be to create a
| link of this name, which would point to the script.
|  Why not use the /etc/rc.local file with execution in background, like:
|  [/etc/rc.local:]
|        ...
|        ...
|        /home/fred/bin/my_daemon.sh &
| [end of file /etc/rc.local]
| or even use directly:

|        /home/fred/bin/proj

| (remember to add a '&' to the end of the line above, if the C++
| program is not yet a real daemon).

thanks Bogdan;

the whole concept is very new to me, so I am learning and trying to
get the bigger picture.

what do you mean by "if the C++ program is not yet a real daemon"?


 I mean "if the C++ program does not use the daemon() function to put
itself in the background". Read 'man daemon', this may be helpful.

if I add
/home/fred/bin/proj &
to the end of /etc/rc.local, how does this re-establish my connection
with the server?


 It doesn't. This just launches your program. You should put some code
in your program to check if it is connected (and if it is not,
reconnect itself).

I mean, is there a return value from proj to let init know to restart
it?


 Not as far as I know. Adding an '&' to the command line returns
whatever the program returns or something like that. Test it to see it.

what proj does is;
first connect to the server using uername/password.
send/receive info to/from the server.
if I use isLogged() in my C++ to return a false to init so it restarts
it, is not that the same as getting the C++ code to reconnect with out
needing a daemon?


 No. When init restarts the program, it simply starts the program
again and the program runs from the beginning. You could use the
command line to do such things. But anyway, this would require a
'service xxxx status' command once in a while and more work. The
checking would have to be done manually or by cron. In my opinion,
this is too much work. I'd do it this way:

- put the program in daemon mode, using the daemon() function, unless
the program must be interactive (like it requires constant data input
from the keyboard). If the program is interactive, use the '&' at the
edn of the line (so it won't stop init and system startup from going
on) and don't use the daemon() function.
- connect
- talk to server
- repeatedly check if the program is connected using the isLogged()
function, perhaps from a new thread (pthread_create() or fork() ).
- if it isn't connected, start the connection.

 However, if the program is interactive, I still can't imagine this to
work, because there may be no terminals yet to read data from. To be
more helpful, I need more details (if there are more questions).
Perhaps putting the program startup command in the shell startup
scripts would be more useful (without the '&' ,for example).

Gary Wessle - 3 Paź 2006, 23:46



| | Hi

| | I am experimenting to run my own daemon on start up.

...

 However, if the program is interactive, I still can't imagine this to
work, because there may be no terminals yet to read data from. To be
more helpful, I need more details (if there are more questions).
Perhaps putting the program startup command in the shell startup
scripts would be more useful (without the '&' ,for example).


thanks again Bogdan:
here is more details:

#include "xyzCompany.h"
...

using namespace xyzCompany;
using namespace std;

int main()
{
   xyzType myObj;
   char* username=gary;
   char* password=garyw;

   while(1)
      {
         try {
            myObj.login(username, password);
         }      
         catch(myException f)
            {
               cout << "sample1: unable to connect, retying...." << endl;
               continue;
            }
         break;
      }
      // wait for command line input
      string c;

      while( cin | c){   // cin is a standard input xterm prompt in
         this case
         if (c==end) myObj.logout();
         if (c==dotask1)  myObj.task1();
         if (c==dotask2)  myObj.task2();
         ...
      }        

}


say I lose connection with the server, then I need to re-connect
asap. cron job has a 1 minute minimum, that is too long, I need it
checked few times per second.
xyzType provide bool isLogged()

say I lose power, the box reboots, I have auto-login-on, and a
line "xterm &" in my .bash_profile to start xterm on x login, and
"path/to/proj" in .bashrc  to start myProject when ever a xterm
starts (not good because it will start a new instance every time I
open a new xterm which is not what I want, once only is what I am
after).

Bogdan (bogdro) - 4 Paź 2006, 07:32




| | Hi

| | I am experimenting to run my own daemon on start up.

| ...

|  However, if the program is interactive, I still can't imagine this to
| work, because there may be no terminals yet to read data from. To be
| more helpful, I need more details (if there are more questions).
| Perhaps putting the program startup command in the shell startup
| scripts would be more useful (without the '&' ,for example).

thanks again Bogdan:
here is more details:

#include "xyzCompany.h"
...

using namespace xyzCompany;
using namespace std;

int main()
{
   xyzType myObj;
   char* username=gary;
   char* password=garyw;

   while(1)
      {
    try {
       myObj.login(username, password);
    }      
    catch(myException f)
       {
          cout << "sample1: unable to connect, retying...." << endl;
          continue;
       }
    break;
      }
      // wait for command line input
      string c;

      while( cin | c){   // cin is a standard input xterm prompt in
         this case
         if (c==end) myObj.logout();
    if (c==dotask1)  myObj.task1();
    if (c==dotask2)  myObj.task2();
    ...
      }        
}

say I lose connection with the server, then I need to re-connect
asap. cron job has a 1 minute minimum, that is too long, I need it
checked few times per second.
xyzType provide bool isLogged()


 OK, now all is more clear. Running the program form the .bashrc or
.bash_profile startup script is a good idea. Look below for a method
of checking whether the program is already running.

 Read the following man pages: pthread_create, pthread_exit. It is
very simple to create a new thread, which would constantly check if
the program is connected. Something similar to:

#include <pthread.h

pthread_t threadID;

int main() {
        ...
        pthread_create ( &threadID, NULL, &checkForConn, NULL );
        // the '&' in front of 'checkForConn' may not be necessary.
        ...

}


void checkForConn() {

        while (1) {
                if ( ! myObj.isLogged() ) {
                        // do reconnect here
                }
                //else pthread_yield(); // give away time for others
        }

}


 Needs '-lpthread' added to compilation command line, preferably near
the end.

 This should work well and is easy to learn.

 If your while(cin| c) loop isn't too long and doesn't take long to
any of the functions called, you may check the status there, instead
of creating a new thread, like this:

        while ( cin | c ) {
                if ( ! myObj.isLogged() ) {
                        // do reconnect
                }
                if ( c == .....
                ...
        }

 If using the pthread library is impossible, read 'man 2 fork'
instead. Forking is a little bit less logical, as the old and the new
process both start/continue execution at the same place, right after
the fork() call. You need to check the result of fork() and branch
accordingly.

say I lose power, the box reboots, I have auto-login-on, and a
line "xterm &" in my .bash_profile to start xterm on x login, and
"path/to/proj" in .bashrc  to start myProject when ever a xterm
starts (not good because it will start a new instance every time I
open a new xterm which is not what I want, once only is what I am
after).


 Check the result of the command
        ps -A |grep proj
 in the .bashrc file. Read 'man grep' to be sure. Here's what I have
done some time ago:

uname -r | grep -q "2.6.16"
if ( [ $? == 0 ]); then export ALSA_OUT_PORT=17:0
 else export ALSA_OUT_PORT=65:0
fi;

 The "$?" means the value returned by the previous command. Lookup
'man grep' for return values.

KDE nie startuje problem z mysz? ? a mo?e co? dalej ?
automatyczne uruchamianie demonów podczas startu systemu
kolejnosc startu rc.d2
  • kolmetal olsztyn
  • komputer e2180 2gb 1066mhz 8800gs p5kc dzwiek
  • cisnienie hydrostatyczne opis
  • wtapianie renderow
  • herb teamu do gry wazne
  • aplikacje;kompas;elektroniczny
  • do podstrony 90
  • SUPERMARKETY KAUFLAND
  • ciekawe miejsca na foto bialystok
  • Kolekcja wiadomości z grup dyskusyjnych • Strona Główna